Systems and Methods for Converting and Resolving Structured Queries as Search Queries

ABSTRACT

Systems and methods for processing structured queries as search queries are provided herein. An example system includes a structured query language (SQL) parser that parses a SQL structured query into a tree structure; an analyzer module that generates a logical plan from the tree structure; a planner module that generates an optimized logical plan from the logical plan; and an execution module that: generates a physical plan from the optimized logical plan, the physical plan comprising a search query that can be executed by a search engine; and returns results of the search query to a client.

CROSS REFERENCE TO RELATED APPLICATIONS

N/A

FIELD OF THE PRESENT TECHNOLOGY

The present technology relates generally to query processing systems,and more particularly, but not by limitation, to systems and methodsthat convert and resolve structured queries (e.g., SQL formattedqueries) as search queries, allowing for operations such as full-textsearching and other similar search query operations using input in theform of a structured query.

SUMMARY

Various embodiments of the present technology include a search enginesystem that converts and processes structured queries as search queries,the system comprising: a structured query language (SQL) parser thatparses a SQL structured query into a tree structure; an analyzer modulethat generates a logical plan from the tree structure; a planner modulethat generates an optimized logical plan from the logical plan; and anexecution module that generates a physical plan from the optimizedlogical plan, the physical plan comprising a search query that can beexecuted by a search engine; and returns results of the search query toa client.

Various embodiments of the present technology include a systemcomprising: a processor; and a memory for storing executableinstructions, the processor executing the instructions to: allow a userto input a structured query language (SQL) request; convert the SQLrequest into a physical plan comprising a search query that can beexecuted by a search engine using pattern matching implemented as a ruleset; performing a search query using the physical plan to produceresults; and return a response to the SQL structured query based on theresults of the search query.

Various embodiments of the present technology include a methodcomprising: receiving a structured query language (SQL) query from auser; converting the SQL query to an executable search query by: parsingthe SQL structured query into a tree structure; generating a logicalplan from the tree structure; generating an optimized logical plan fromthe logical plan; and generating a physical plan from the optimizedlogical plan, the physical plan being folded into a search query thatcan be executed by a search engine; and returning results of the searchquery to a client.

BRIEF DESCRIPTION OF THE DRAWINGS

Certain embodiments of the present technology are illustrated by theaccompanying figures. It will be understood that the figures are notnecessarily to scale and that details not necessary for an understandingof the technology or that render other details difficult to perceive maybe omitted. It will be understood that the technology is not necessarilylimited to the particular embodiments illustrated herein.

FIG. 1 is a high level schematic diagram of computing architecture forpracticing aspects of the present technology.

FIG. 2 illustrates an example parsing of a SQL query into a logicalplan.

FIG. 3 illustrates an example validation and resolving of components orobjects in a logical plan.

FIG. 4 illustrates an example aliasing process of a logical plan.

FIG. 5 illustrates a process or resolving hidden references in a logicalplan.

FIG. 6 illustrates optimizing of a logical plan.

FIG. 7 illustrates conversion of a logical plan into a physical plan.

FIG. 8 illustrates analyzed versus non-analyzed versions of physicalplans.

FIG. 9 illustrates another example analyzed versus non-analyzed versionsof physical plans.

FIG. 10 illustrates an example sorting physical plan.

FIG. 11 illustrates various example physical plans generated fromstructure queries, which allow for full text searches.

FIG. 12 illustrates an example physical plan that allows for a groupingfunction based on a “by” and a “having” conditions.

FIG. 13 illustrates example nested documents that correspond to theexpressions illustrated in FIG. 12.

FIG. 14 is a flowchart of an example method that involves both theconversion of a structured query into a search query, as well as theexecution of the search query and the return of results of the searchquery in a row set format.

FIG. 15 is an example conversion of a structured query (SQL) into aphysical plan using the aspects of the present disclosure.

FIG. 16 is a diagrammatic representation of an example machine in theform of a computer system.

DETAILED DESCRIPTION

The present disclosure is directed to various embodiments of systems andmethods that implement a structured query conversion system that is aSQL interface to a search and analytics engine such as Elasticsearch™.In general, Elasticsearch™ is a distributed, RESTful search andanalytics engine. Generally described, the structured query conversionsystem acts as a convertor or translator allowing traditional formal SQLqueries to be executed against Elasticsearch™ indices without anymodifications to the SQL queries on the end user side. That is, the userneed only know how to format a SQL query and is not required tounderstand or convert or modify any part of the SQL query into inputthat can be used by the Elasticsearch™ search system. The structuredquery conversion system also provides the user with a response that isin a familiar structured query response format, despite being resolvedas a search query.

In some embodiments, the structured query conversion systems and methodsdisclosed herein map a given SQL query, if possible, to at least oneElasticsearch query DSL. It will be understood that DSL stands forDomain Specific Language that is a computer language specialized to aparticular application domain. Elasticsearch™ utilizes query DSL; aspecific language for doing queries (searches and aggregations).

Since Elasticsearch™ is not a relational database structured queryconversion systems of the present disclosure are created withElasticsearch™ in mind first and SQL second. In fact, even the grammarutilized herein introduces Elasticsearch™ specific components that haveno concept in ANSI SQL.

In general, an example architecture of an example structured queryconversion system of the present disclosure utilizes both logical andphysical algebra to convert a SQL query to a search query. Thestructured query conversion system uses an extensible algebraic andlogical set of operators to describe an operation to its underlyingengine. The engine maps a user query into logical algebra (e.g., logicalplan) and then translates this into physical algebra (e.g., physicalplan).

In some embodiments, the structured query conversion system uses a ruleset to identify patterns in the logical plan. In more detail, the ruleset provides a way to identify relevant patterns inside the plans thatcan be worked upon. In other words, the use of a logical plan, whichrepresents what the user has requested in SQL format and a physicalplan, which is what the engine needs to execute based on the userrequest. To manipulate the plans, the engine performs one or moremethods of pattern matching implemented as rules that get applied overand over until no matches are found. An example of a rule would beexpanding to actual concrete references.

Each rule executes against one particular pattern that it tries toidentify in the logical plan. For example one dedicated rule canconverts a star (*) into its respective fields. Essentially each ruleoffers the solution for one individual problem. In a rule set, one ormultiple rules can match a particular use query which is on purpose—somequeries are more complicated than others. However by using a rulesengine approach, the query is broken down into individual_known_patterns (or problems) that can be solved in isolation leading tothe resolution of the entire query/problem.

Conceptually, the systems and methods herein recognize that a buildingoperation of the SQL engine is defined by an action, namely a rulepackage that accepts one immutable tree and transforms it to another anddifferent immutable tree.

Each rule examines the logical plan for a certain pattern that it canidentify and then transform in to a component of a search query.

In some embodiments, the structured query conversion system utilizesthree main types of trees: (1) a logical plan that is a logicalrepresentation of a user query. Any transformation of this plan shouldresult in an equivalent physical plan or other modified form of thelogical plan. That is, for the same input, it will generate the sameoutput. A physical plan (2) is an executable representation of a userquery. This plan needs to translate to at least one query toElasticsearch™. Many queries can be connected together, which isfunctionally similar to JOIN codes of SQL. Thus, different strategiesfor generating a physical plan will be available depending on acomputing cost (either monetary or computational resources) to the enduser.

Another tree type (3) is an expression tree. Both the logical andphysical plan each comprises an expression tree that needs to beincorporated into the resultant search query.

Each of these types of trees inside the structured query conversionsystem has at least the following properties: immutability (each nodeand its properties are immutable, where a change in a property resultsin a new node which results in a new tree); resolution (due to thealgebraic nature of SQL, each tree has the notion of resolution whichindicates whether it has been resolved or not. A node can be resolvedonly if it and its children have all been resolved; and traversal (eachtree can be traversed top-to-bottom/pre-order/parents-first orbottom-up/post-order/children-first. The difference in the traversaldepends on the pattern that is being identified).

In some embodiments, a flow inside the conversion engine includes thefollowing processes. In a first process the conversion engine receives aquery from a user in SQL format. In a second process the query is parsedand transformed into an unresolved abstract syntax tree (AST) or logicalplan. The logical plan gets analyzed and resolved in a third process.The logical plan gets optimized in a fourth process. In a fifth process,the logical plan gets transformed into a physical plan. In a sixthprocess, the physical plan gets mapped and then folded into anElasticsearch™ query. The Elasticsearch™ query gets executed in aseventh and final step.

In some embodiments, the systems and methods allow for pattern matchingand to implement the these concepts, several choices have been made inthe conversion engine, which are described herein.

In some instances, components of the system comprise a tokenizer and alexer of SQL grammar. The system will translate a user query into an ASTtree or logical plan. The system also cooperates to ensure that the userquery (e.g., SQL query) is syntactically valid. The system also performsbasic inspection of the logical plan for gathering critical informationfor the main analysis. This stage is separate from the analysis phasesince the system performs asynchronous/remote calls to Elasticsearch. Acluster represents an Elasticsearch system, made out of one or multiplenodes or Elasticsearch instances. The SQL implementation while runninginside Elasticsearch, can send these requests either to the local or aseparate Elasticsearch system or cluster.

In some embodiments, the system performs logical plan analysis,resolution and, verification. The system also ensures that the userquery is actually valid and semantically valid. The system can alsotransform the resolved logical plan into a semantically equivalent tree,meaning for the same input, the same output is produced.

In some embodiments, a planner of the system performs query planning.The planning is made up of two components, a code mapper that maps thelogical plan to a physical plan and a folder module that folds orrolls-up the physical plan into an Elasticsearch™.

The system then performs actual execution of the query, resultsretrieval, extractions and translation into a row and set format. Thisformat is familiar to users who utilize SQL and thus the user not onlyprovides a SQL format input, but receives a SQL format output.

FIG. 1 is an example architecture of a structured query conversionsystem (referred to as system 100) that receives SQL queries, translatesthem into Elasticsearch™ queries, and returns results to a user. In someembodiments, the results are provided in a format that is similar to howSQL query results are structured. An end user device 110 such as an enduser computing system can couple with the system 100 to providestructured queries and receive search results from the system 100. Theend user device 110 can communicatively couple with the system 100 overa network 112.

In general, the structured query conversion system 100 comprises astructured query language (SQL) parser (SQL parser 102), an analyzermodule 104, a planner module 106, and an execution module 108.

Generally speaking, the SQL parser 102 receives and parses a SQLstructured query into a tree structure. The analyzer module 104generates a logical plan from the tree structure, and the planner module106 generates an optimized logical plan from the logical plan. In someembodiments, the execution module 108 generates a physical plan from theoptimized logical plan. To be sure, the physical plan comprising asearch query that can be executed by a search engine. The executionmodule 108 also returns results of the search query to a client. Again,this can include a result that is in a format that would be expected fora SQL query, such as a row and set format.

In some embodiments, the SQL parser 102 generally functions as a parserand tokenizer and the analyzer module 104 includes lexer functions,although it will be understood that the functions of one or more modulescan be combined.

In one or more embodiments, the system 100 is generally configured toallow a user to input a structured query language (SQL) request. Thesystem 100 then converts the SQL request into a physical plan comprisinga search query that can be executed by a search engine using patternmatching implemented as a rule set. The system also performs a searchquery using the physical plan to produce results and then returns aresponse to the SQL structured query based on the results of the searchquery.

According to some embodiments, the SQL parser 102 is configured toreceive a SQL format (e.g., structured) query from a user. In someembodiments, the system 100 can provide a customer facing GUI thatallows a user to enter a SQL query. In another embodiment, SQL queriesare received as a message or stream. Regardless of the method by whichthe system 100 receives a SQL query, the SQL parser 102 parses the SQLstructured query into a tree structure 202. The tree structure includescomponents of the SQL search, which are represented and referred to astokens. For example, components of the tree structure 202 include‘queryNoWidth’; ‘expression’; and ‘predicated’ tokens.

An example parsing of a SQL query into a logical plan is illustrated inFIG. 2. In FIG. 2, a parsed tree 202 is generated from a SQL formatquery. This tree structure 202 includes all the terms of the SQL formatquery. This tree structure 202 is transformed into a logical plan 204.

The original structured query 206 is illustrated as well. The processfor generating an example Elasticsearch™ query is described in greaterdetail herein. To be sure, a physical plan created from the logical plan204 is utilized to generate a search query. Methods for furtherprocessing the logical plan, generating a physical plan from a logicalplan, and generating a search query from a physical plan are disclosedin greater detail herein.

In FIG. 3, output of the analyzer module 104 is illustrated whichvalidates the SQL query and resolve objects in the SQL query and theinitial logical plan 204 such as tables, columns, functions, aliases,and namespaces—just to name a few. The resolved logical plan 208 of theinitial logical plan 204 is then generated. That is, the analyzer modulewill validate components of the structured query, so as to ensure thatthe components are syntactically valid.

In various embodiments, the analyzer module 104 is configured to performaliasing of a logical plan (or a resolved logical plan) into an aliasedlogical plan. An example aliasing operation is illustrated in FIG. 4,where a logical plan 402 is processed through aliasing into an aliasedlogical plan 404.

Some embodiments allow for the analyzer module 104 to resolve hiddenreferences. For example, as in FIG. 5, a logical plan 502 may includehidden references that are resolved by converting the logical plan 502into a second logical plan 504 that allows for resolution of hiddenreferences. A corresponding structured query 506 is provided forillustration. Of note, a physical plan created from the second logicalplan 504 is required to generate a search query.

In general, hidden references refer to references that are available butget filtered by intermediate levels of processing and thus cannot beresolved higher up. This can cause a valid query to fail forcing theuser to modify the query. However the engine can look for this ‘pattern’and unhide the reference accordingly.

These methods are generally referred to as resolving components of thestructured query. In one or more instances, the analyzer module 104 cangenerate a resolved logical plan from a tree structure using aliasing ofat least a portion of the components of the structured query. The act ofresolving a logical plan involves resolving specific components of thecomponents of the structured query, so as to ensure that the componentsare semantically valid. Thus, using both validating and resolving, thelogical plan can be both syntactically and semantically valid.

In some embodiments, a logical plan can be optimized prior to conversioninto a physical plan. FIG. 6 illustrates an example process foroptimizing an initial logical plan 602 into an optimized logical plan604. A corresponding structured query 606 used to generate the optimizedlogical plan 604 is illustrated. Of note, a physical plan created fromthe optimized logical plan 604 is required to generate any resultantsearch query. In some embodiments, the process illustrated in FIG. 6 isperformed by the planner module 106. The planner module 106 generates anoptimized logical plan from a logical plan (could be resolved and/oraliased) by performing any of operator simplifications, operatorpruning, execution simplification, and execution elimination, andcombinations and permutations thereof.

In various embodiments, the planner module 106 is also configured toconvert the logical plan into a physical plan, as illustrated in FIG. 7.In general, a physical plan 702 comprises automatically generatedexecutable code that can be executed by a search engine to resolve theoriginal SQL structured query. The physical plan 702 is generated from alogical plan 704. An example structured query 706 used to generate thephysical plan 702 is illustrated.

According to some embodiments, the execution module 108 executes thephysical plan and/or search query and then streams results to the enduser. The execution module 108 can also keep track of references andhandles conversion of results into a tabular format (e.g., aggregationsas a tree vs as a table). The execution module also allows for data typeconversion methods.

In some embodiments, the system 100 can perform both analyzed andnon-analyzed queries. Examples of analyzed operations within searchqueries include full-text search and default search for strings (textbased). These methods also include a non-analyzed field, such as when akeyword is included in the search query. Examples of non-analyzedoperations include, but are not limited to, aggregations and exactmatches, which can be used as default for non-string analysis (e.g., nottextual). Non-analyzed operations are also used for processes such assorting and aggregation. Examples of analyzed versus non-analyzedphysical plans are illustrated in FIG. 8. An example match query 802(e.g., analyzed) is compared with an example term query 804 (e.g.,not-analyzed) for the search query “SELECT . . . WHERE gender=‘M’”. FIG.9 illustrates further examples with a “source and include” query 902compared with a docvalue_fields query 904.

For context, analysis with respect to Elasticsearch and that of a searchengine are somewhat different. Search engines are based around thecontext of an inverted index (which indicates the location where a wordappears). To properly identify variations for a text, it is being“broken down” that is deconstructed into its root form: (it is beinglower cased, punctuation and space removed, prefix/suffixes removed).

In contract a not-analyzed form, in the context of a search-engine (andElasticsearch) means the exact value as the user added it. Anot-analyzed form can be used for computations (and aggregations) whilethe analyzed form for full-text searches. The vice-versa does not apply(as it produces incorrect results and is prohibitive computationalwise).

A sorting physical plan is illustrated in FIG. 10, which corresponds toa structured query “SELECT . . . ORDER BY gender.” FIG. 11 illustratesphysical plans generated from structure queries, which allow for fulltext searches. To be sure, SQL does not allow for or support analyticalsearching and/or full-text searching. Thus, the conversion of thelogical plan to a physical plan increases the granularity andspecificity of a corresponding structured query. Each physical plan ispaired with a structured query from which it was created. The physicalplan is on top and the structured query is positioned below the physicalplan.

Also, the search queries generated using logical and physical plans asdisclosed herein allow for performing functions such as aggregations(e.g., average, count, maximum). These functions can also be mapped ontometrics aggregations. Other functions such as scalar date extraction caneasily be performed through physical plan scripting. Monotonic functionsare also advantageously optimized using scalar processes.

FIG. 12 illustrates an example physical plan that allows for a groupingfunction based on a “by” and a “having” conditions. Bucket aggregationoccurs through the SELECT and WHERE operators, while the metric isdefined using the aggregate_function and GROUP BY operators. The HAVINGaggregate_function operator provides a pipeline aggregationfunctionality.

In general, a bucket aggregation is an aggregation (a function thatworks on multiple values) that produces a group or a bucket of values.It is used to “bucket” values on a criteria (for example break down atime interval into days or other delineated period of time).

As noted above, the search queries (e.g., Elasticsearch™) herein can beadapted to allow for specific SQL operations such as JOIN operationsusing nested and parent-child relationships. An example JOIN searchquery function includes “SELECT dep.dept_name, last_name FROM emp.empWHERE emp_no=10020”. Another example JOIN=search query function includes“SELECT last_name FROM emp.emp WHERE dep.dept_name=‘Production’”. Anexample representation of nested documents is illustrated in FIG. 13.

FIG. 14 is a flow diagram of an example method. The method involves boththe conversion of a structured query into a search query, as well as theexecution of the search query and the return of results of the searchquery in a row set format.

In some embodiments, the method comprises a step 1402 of receiving astructured query language (SQL) query from a user. Once received, theSQL query is converted into an executable search query using a set ofoperations. In some embodiment, the method includes a step 1404 ofparsing the SQL structured query into a tree structure. Once the treestructure is generated, the method includes a step 1406 of generating alogical plan from the tree structure. This logical plan is theequivalent of a logical algebraic expression of the tree structure. Insome instances, optional steps of validating and resolving variouscomponents of the tree structure can be performed so as to ensure thatthe components of the tree structure/logical plan created are bothsemantically and syntactically valid.

In some embodiments, the method includes a step 1408 of generating anoptimized logical plan from the logical plan, as well as a step 1410 ofgenerating a physical plan from the optimized logical plan. This processincludes converting the logical algebraic representation of the logicalplan into a physical algebraic expression. The optimized logical planand physical plan are equivalent to one another. The physical plan canbe in the form of an executable instruction set.

Next, the method includes a step 1412 of folding the physical plan intoa search query that can be executed by a search engine. The search queryis a created from the executable instruction set.

Once the search is performed, the method includes a step 1414 ofreturning results of the search query to a client. Again, the resultsare generated and returned in a row and set format that represents whatthe user would expect when receiving a response to a structured query.Although the format is similar, the content included in the response canbe far more robust than would be available if a pure SQL query wereexecuted. That is, converting the structured query into a search queryallows for the structured query to be effectively run as, for example, afull text search, which is impossible using SQL.

FIG. 15 illustrates an example conversion of a structured query (SQL)1502 into a physical plan 1504 using the aspects of the presentdisclosure provided herein.

FIG. 16 is a diagrammatic representation of an example machine in theform of a computer system 1, within which a set of instructions forcausing the machine to perform any one or more of the methodologiesdiscussed herein may be executed. In various example embodiments, themachine operates as a standalone device or may be connected (e.g.,networked) to other machines. In a networked deployment, the machine mayoperate in the capacity of a server or a client machine in aserver-client network environment, or as a peer machine in apeer-to-peer (or distributed) network environment. The machine may be apersonal computer (PC), a tablet PC, a set-top box (STB), a personaldigital assistant (PDA), a cellular telephone, a portable music player(e.g., a portable hard drive audio device such as an Moving PictureExperts Group Audio Layer 3 (MP3) player), a web appliance, a networkrouter, switch or bridge, or any machine capable of executing a set ofinstructions (sequential or otherwise) that specify actions to be takenby that machine. Further, while only a single machine is illustrated,the term “machine” shall also be taken to include any collection ofmachines that individually or jointly execute a set (or multiple sets)of instructions to perform any one or more of the methodologiesdiscussed herein.

The example computer system 1 includes a processor or multipleprocessor(s) 5 (e.g., a central processing unit (CPU), a graphicsprocessing unit (GPU), or both), and a main memory 10 and static memory15, which communicate with each other via a bus 20. The computer system1 may further include a video display 35 (e.g., a liquid crystal display(LCD)). The computer system 1 may also include input device(s) 30 (alsoreferred to as alpha-numeric input device(s), e.g., a keyboard), acursor control device (e.g., a mouse), a voice recognition or biometricverification unit (not shown), a drive unit 37 (also referred to as diskdrive unit), a signal generation device 40 (e.g., a speaker), and anetwork interface device 45. The computer system 1 may further include adata encryption module (not shown) to encrypt data.

The drive unit 37 includes a machine-readable medium 50 (which may be acomputer readable medium) on which is stored one or more sets ofinstructions and data structures (e.g., instructions 55) embodying orutilizing any one or more of the methodologies or functions describedherein. The instructions 55 may also reside, completely or at leastpartially, within the main memory 10 and/or within the processor(s) 5during execution thereof by the computer system 1. The main memory 10and the processor(s) 5 may also constitute machine-readable media.

The instructions 55 may further be transmitted or received over anetwork (e.g., network 150 or network 520, see FIG. 1 and FIG. 5,respectively) via the network interface device 45 utilizing any one of anumber of well-known transfer protocols (e.g., Hyper Text TransferProtocol (HTTP)). While the machine-readable medium 50 is shown in anexample embodiment to be a single medium, the term “computer-readablemedium” should be taken to include a single medium or multiple media(e.g., a centralized or distributed database and/or associated cachesand servers) that store the one or more sets of instructions. The term“computer-readable medium” shall also be taken to include any mediumthat is capable of storing, encoding, or carrying a set of instructionsfor execution by the machine and that causes the machine to perform anyone or more of the methodologies of the present application, or that iscapable of storing, encoding, or carrying data structures utilized by orassociated with such a set of instructions. The term “computer-readablemedium” shall accordingly be taken to include, but not be limited to,solid-state memories, optical and magnetic media, and carrier wavesignals. Such media may also include, without limitation, hard disks,floppy disks, flash memory cards, digital video disks, random accessmemory (RAM), read only memory (ROM), and the like. The exampleembodiments described herein may be implemented in an operatingenvironment comprising software installed on a computer, in hardware, orin a combination of software and hardware.

One skilled in the art will recognize that the Internet service may beconfigured to provide Internet access to one or more computing devicesthat are coupled to the Internet service, and that the computing devicesmay include one or more processors, buses, memory devices, displaydevices, input/output devices, and the like. Furthermore, those skilledin the art may appreciate that the Internet service may be coupled toone or more databases, repositories, servers, and the like, which may beutilized in order to implement any of the embodiments of the disclosureas described herein.

The corresponding structures, materials, acts, and equivalents of allmeans or step plus function elements in the claims below are intended toinclude any structure, material, or act for performing the function incombination with other claimed elements as specifically claimed. Thedescription of the present technology has been presented for purposes ofillustration and description, but is not intended to be exhaustive orlimited to the present technology in the form disclosed. Manymodifications and variations will be apparent to those of ordinary skillin the art without departing from the scope and spirit of the presenttechnology. Exemplary embodiments were chosen and described in order tobest explain the principles of the present technology and its practicalapplication, and to enable others of ordinary skill in the art tounderstand the present technology for various embodiments with variousmodifications as are suited to the particular use contemplated.

Aspects of the present technology are described above with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems) and computer program products according to embodiments of thepresent technology. It will be understood that each block of theflowchart illustrations and/or block diagrams, and combinations ofblocks in the flowchart illustrations and/or block diagrams, can beimplemented by computer program instructions. These computer programinstructions may be provided to a processor of a general purposecomputer, special purpose computer, or other programmable dataprocessing apparatus to produce a machine, such that the instructions,which execute via the processor of the computer or other programmabledata processing apparatus, create means for implementing thefunctions/acts specified in the flowchart and/or block diagram block orblocks.

These computer program instructions may also be stored in a computerreadable medium that can direct a computer, other programmable dataprocessing apparatus, or other devices to function in a particularmanner, such that the instructions stored in the computer readablemedium produce an article of manufacture including instructions whichimplement the function/act specified in the flowchart and/or blockdiagram block or blocks.

The computer program instructions may also be loaded onto a computer,other programmable data processing apparatus, or other devices to causea series of operational steps to be performed on the computer, otherprogrammable apparatus or other devices to produce a computerimplemented process such that the instructions which execute on thecomputer or other programmable apparatus provide processes forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods and computer program products according to variousembodiments of the present technology. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof code, which comprises one or more executable instructions forimplementing the specified logical function(s). It should also be notedthat, in some alternative implementations, the functions noted in theblock may occur out of the order noted in the figures. For example, twoblocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. It will also be notedthat each block of the block diagrams and/or flowchart illustration, andcombinations of blocks in the block diagrams and/or flowchartillustration, can be implemented by special purpose hardware-basedsystems that perform the specified functions or acts, or combinations ofspecial purpose hardware and computer instructions.

In the following description, for purposes of explanation and notlimitation, specific details are set forth, such as particularembodiments, procedures, techniques, etc. in order to provide a thoroughunderstanding of the present invention. However, it will be apparent toone skilled in the art that the present invention may be practiced inother embodiments that depart from these specific details.

Reference throughout this specification to “one embodiment” or “anembodiment” means that a particular feature, structure, orcharacteristic described in connection with the embodiment is includedin at least one embodiment of the present invention. Thus, theappearances of the phrases “in one embodiment” or “in an embodiment” or“according to one embodiment” (or other phrases having similar import)at various places throughout this specification are not necessarily allreferring to the same embodiment. Furthermore, the particular features,structures, or characteristics may be combined in any suitable manner inone or more embodiments. Furthermore, depending on the context ofdiscussion herein, a singular term may include its plural forms and aplural term may include its singular form. Similarly, a hyphenated term(e.g., “on-demand”) may be occasionally interchangeably used with itsnon-hyphenated version (e.g., “on demand”), a capitalized entry (e.g.,“Software”) may be interchangeably used with its non-capitalized version(e.g., “software”), a plural term may be indicated with or without anapostrophe (e.g., PE's or PEs), and an italicized term (e.g., “N+1”) maybe interchangeably used with its non-italicized version (e.g., “N+1”).Such occasional interchangeable uses shall not be consideredinconsistent with each other.

Also, some embodiments may be described in terms of “means for”performing a task or set of tasks. It will be understood that a “meansfor” may be expressed herein in terms of a structure, such as aprocessor, a memory, an I/O device such as a camera, or combinationsthereof. Alternatively, the “means for” may include an algorithm that isdescriptive of a function or method step, while in yet other embodimentsthe “means for” is expressed in terms of a mathematical formula, prose,or as a flow chart or signal diagram.

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to be limiting of the invention. Asused herein, the singular forms “a”, “an” and “the” are intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. It will be further understood that the terms “comprises”and/or “comprising,” when used in this specification, specify thepresence of stated features, integers, steps, operations, elements,and/or components, but do not preclude the presence or addition of oneor more other features, integers, steps, operations, elements,components, and/or groups thereof.

It is noted at the outset that the terms “coupled,” “connected”,“connecting,” “electrically connected,” etc., are used interchangeablyherein to generally refer to the condition of beingelectrically/electronically connected. Similarly, a first entity isconsidered to be in “communication” with a second entity (or entities)when the first entity electrically sends and/or receives (whetherthrough wireline or wireless means) information signals (whethercontaining data information or non-data/control information) to thesecond entity regardless of the type (analog or digital) of thosesignals. It is further noted that various figures (including componentdiagrams) shown and discussed herein are for illustrative purpose only,and are not drawn to scale.

While specific embodiments of, and examples for, the system aredescribed above for illustrative purposes, various equivalentmodifications are possible within the scope of the system, as thoseskilled in the relevant art will recognize. For example, while processesor steps are presented in a given order, alternative embodiments mayperform routines having steps in a different order, and some processesor steps may be deleted, moved, added, subdivided, combined, and/ormodified to provide alternative or sub-combinations. Each of theseprocesses or steps may be implemented in a variety of different ways.Also, while processes or steps are at times shown as being performed inseries, these processes or steps may instead be performed in parallel,or may be performed at different times.

While various embodiments have been described above, it should beunderstood that they have been presented by way of example only, and notlimitation. The descriptions are not intended to limit the scope of theinvention to the particular forms set forth herein. To the contrary, thepresent descriptions are intended to cover such alternatives,modifications, and equivalents as may be included within the spirit andscope of the invention as defined by the appended claims and otherwiseappreciated by one of ordinary skill in the art. Thus, the breadth andscope of a preferred embodiment should not be limited by any of theabove-described exemplary embodiments.

What is claimed is:
 1. A search engine system that converts andprocesses structured queries as search queries, the system comprising: astructured query language (SQL) parser that parses a SQL structuredquery into a tree structure; an analyzer module that generates a logicalplan from the tree structure; a planner module that generates anoptimized logical plan from the logical plan; and an execution modulethat: generates a physical plan from the optimized logical plan, thephysical plan comprising a search query that can be executed by a searchengine; and returns results of the search query to a client.
 2. Thesearch engine system according to claim 1, wherein the analyzer moduleis further configured to validate components of the structured query. 3.The search engine system according to claim 2, wherein the analyzermodule is further configured to resolve the components of the structuredquery.
 4. The search engine system according to claim 3, wherein theanalyzer module is further configured to generate a logical plan fromthe tree structure using aliasing of at least a portion of thecomponents of the structured query.
 5. The search engine systemaccording to claim 4, wherein the analyzer module is further configuredto resolve hidden references in the structured query.
 6. The searchengine system according to claim 1, wherein the planner module generatesthe optimized logical plan from the logical plan by performing any ofoperator simplifications, operator pruning, execution simplification,and execution elimination, and combinations and permutations thereof. 7.The search engine system according to claim 1, wherein the physical plancomprises automatically generated executable code that can be executedby a search engine to resolve the SQL structured query.
 8. The searchengine system according to claim 1, wherein the search engine systemperforms a full text search of resources using the physical plan that isbased on the SQL structured query and the results include data obtainedfrom the full text search.
 9. A system, comprising: a processor; and amemory for storing executable instructions, the processor executing theinstructions to: allow a user to input a structured query language (SQL)request; convert the SQL request into a physical plan comprising asearch query that can be executed by a search engine using patternmatching implemented as a rule set; perform a search query using thephysical plan to produce results; and return a response to the SQLstructured query based on the results of the search query.
 10. A method,comprising: receiving a structured query language (SQL) query from auser; converting the SQL query to an executable search query by: parsingthe SQL structured query into a tree structure; generating a logicalplan from the tree structure; generating an optimized logical plan fromthe logical plan; and generating a physical plan from the optimizedlogical plan, the physical plan being folded into a search query thatcan be executed by a search engine; and returning results of the searchquery to a client.
 11. The method according to claim 10, furthercomprising validating components of the structured query, so as toensure that the components are syntactically valid.
 12. The methodaccording to claim 11, further comprising resolving the components ofthe structured query, so as to ensure that the components aresemantically valid.
 13. The method according to claim 12, furthercomprising generating a logical plan from the tree structure usingaliasing of at least a portion of the components of the structuredquery.
 14. The method according to claim 13, further comprisingresolving hidden references in the structured query.
 15. The methodaccording to claim 10, further comprising wherein generating theoptimized logical plan from the logical plan comprises performing any ofoperator simplifications, operator pruning, execution simplification,and execution elimination, and combinations and permutations thereof.16. The method according to claim 10, wherein the physical plancomprises automatically generated executable code that can be executedby a search engine to resolve the SQL structured query.
 17. The methodaccording to claim 16, further comprising performing a full text searchof resources using the physical plan that is based on the SQL structuredquery and the results include data obtained from the full text search.18. The method according to claim 10, wherein converting the SQL queryto an executable search query further comprises mapping components ofthe SQL query into logical algebra and then translating the logicalalgebra into physical algebra.
 19. The method according to claim 10,further comprising folding the physical plan into an Elasticsearchexecutable query.